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^mTH^LAIMS 

Claims 9, 12-16, 58-59, 62-65, and 68-71 are withdrawn herein. Claims 1, 4-6, 8, 28, 32, 
33, 35, 37-42, 49, and 53 are amended. Claims 72 and 73 are added. Claim 36 is canceled. All 
pending claims are reproduced below. 

1 1. (Currently Amended) A computer-implemented method for the intermediation of real 

2 time meetings, comprising: 

3 receiving an indication by a requester system that a requester (R-A) wants to request a 

4 realtime meeting M-A with a target T-A; 

5 sending to a decider system (D) targ e t syst e m of th e targ e t T A a request to conduct a real 
. 6 time meeting M-A ; 

7 queuing the request for the meeting M-A by the decider r e qu e st e r system; 

8 receiving by the decider system (D) an availability status of T-A; 

9 receiving by the decider system (D) an availability status of R-A 

1 0 receiving an indication by the requester system that the a requester (R-B) wants to request 

M a realtime meeting M-B with another target T-B, the meeting M-B to be disjoint in time with the 

1 2 meeting M-A; and such that one of the parties to M-A (R-A or T-A), known as the 'common 

13 party' is also the same as one of the parties to M-B (R-B or T-B) and thus there are only three 

14 distinct parties, the decider D being associated with the common party ; 

1 5 sending to a target syst e m of th e targ e t T B the decider system (D) a request to conduct a 

1 6 real time meeting M-B ; 

1 7 queuing the request for the meeting M-B by the r e qu e st e r decider system, such that at 

1 8 least two distinct meetings, disjoint in time are placed in the queue; 

1 9 receiving by the decider system (D) an availability status of target T-B; 

20 receiving by the decider system (D) an availability status of the requester R-B; 

2 1 initiating one of the two meetings M-A and M-B by connecting the common party 

22 r e qu e st e r and on e of th e targ e ts the other party to that meeting when the r e qu e st e r common party 

23 and th e targ e t that other party are mutually available; and 

24 dequeuing the request for a meeting upon its completion. 
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1 2. (canceled) 

1 3. (Previously Presented) The method of claim 1, wherein a system of the target T-A is 

2 polled to determine the target's availability. 

1 4. (Currently Amended) The method of claim 1 , wherein the system of the target T-A 

2 sends the target's availability status to the requester decider system. 

1 5. (Currently Amended) The method of claim 1 , wherein a system of tho request e r a 

2 party is polled to determine the requestor's party's availability. 

1 6. (Currently Amended) The method of claim 1 , wherein the system of th o requ e st e r a 

2 party sends the request e r's party's availability status to the target decider system. 

1 7. (Original) The method of claim 1 , wherein mutual availability is determined by 

2 checking the availability of the requester and the target. 

1 8 . (Currently Amended) The method of claim 1 , wherein a request is sent to a plurality 

2 of targets and mutual availability is determined when the requester and a quorum of tho targ e ts 

3 ar© all the parties is available. 

1 9. (Withdrawn) A computer-implemented method for the intermediation of realtime 

2 meetings, comprising: 

3 receiving, by a target system from a requester system, an indication that a requester R-A 

4 wants to request a realtime meeting M-A with a target; 

5 queuing the request for M-A by the target system; 

6 receiving, by the target, an availability status of the requester R-A; 

7 receiving, by the target system from a requester system, an indication that a different 

8 requester R-B wants to request a realtime meeting M-B with the target, the meeting M-B to be 

9 disjoint in time with the other meeting M-A; 

10 queuing the requests for M-A and M-B by the target system; 

1 1 receiving, by the target, an availability status of the requester R-B; and 
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12 connecting the requester and one of the targets who is available to the requester when 

13 the requester and the target are mutually available; and 

14 dequeuing the request for a meeting upon its completion. 
1 10. (Canceled) 

1 11. (canceled) 

1 12. (Withdrawn) The method of claim 9, wherein the system of the target sends the 

2 target's availability status to the requester. 

1 13. (Withdrawn) The method of claim 9, wherein a system of the requester R-A is 

2 polled to determine the requester's availability. 

1 14. (Withdrawn) The method of claim 9, wherein the system of the requester R-A sends 

2 the requester's availability status to the target. 

1 15. (Withdrawn) The method of claim 9, wherein mutual availability is determined by 

2 checking the availability of the requester and the target. 

1 16. (Withdrawn) The method of claim 9, wherein a request is sent to a plurality of 

2 targets and mutual availability is determined when the requester and a quorum of the targets are 

3 available. 

1 17-27. Cancelled 

1 28. (Currently Amended) A computer-implemented method for the intermediation of real 

2 time meetings, comprising: 

3 receiving an indication that a requester party R-A wants to request a real time meeting M- 

4 A with a target party T-A; 

5 receiving an indication that the requester party R-B wants to request a real time meeting 

6 M-B with a target party T-B, the meeting M-B to be disjoint in time with the other meeting M-A; 

7 receiving information indicating the availability of the requester party R-A and the target 

8 party T-A to participate in the real time meeting M-A, the information sent by the requester party 

9 RA and the target party T-A and indicating a desire of a human being to take part in a meeting; 
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1 0 receiving information indicating the availability of the requester party Rjl and the target 

1 1 party T-B to participate in the real time meeting M-B, the information sent by the requester party 

12 RrB and the target party and indicating a desire of a human being to take part in a meeting; 

1 3 queuing the requests for meetings M-A and M-B by the requester system, such that at 

1 4 least two distinct meetings, disjoint in time, are placed in the queue, and such that one of the 

15 parties to M-A, known as the 'common party' is also the same as one of the parties to M-B and 

16 thus there are only 3 rather than 4 distinct parties : 

1 7 determining that the r e qu e stor common party and one of the non-common target parties 

1 8 T A and T B are mutually available to participate in the real time meeting, in response to the 

19 received information; 

20 responsive to the determination that the requostor common p arty and the target non- 

2 1 common party to M-A T-A are mutually available to participate in the real time meeting M-A, 

22 initiating the real time meeting M-A; and 

23 responsive to the determination that the requ e stor common p arty and the non-common 

24 target-party to M-B T-B are mutually available to participate in the real time meeting M-B, 

25 initiating the real time meeting M-B. 

1 29. (Original) The method of claim 28, wherein the initiating further comprises 

2 informing the requester party and one or more target parties that they should initiate 

3 communication. 

1 30. (Original) The method of claim 28, wherein the initiating further comprises 

2 requesting the requester party and one or more target parties to open a connection. 

1 31. (Original) The method of claim 28, wherein the availability of the requester party 

2 and one or more target parties is determined by checking at least one of: start or end of a call; 

3 other use of phone; recent activity at computer input devices; conversation near microphone; 

4 lights turned on/off; weight in chair or on floor; a motion sensor; opening/closing of door; 

5 spoken commands; computer keyboard/mouse based commands; touchtone commands; and 

6 scheduled periods of availability. 

1 32. (Currently Amended) A system for intermediation of real time meetings, 

2 comprising: 
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a requester system fcA for receiving a request from a requester party to initiate a real 
time meeting M-A with a target party T-A; 

mi a requester sy stem R-B for reiving a request from the , requester party to initiate a 
real time meeting M-B with a targe, party T-B, the meetings M-A and M-B being disjoin, in 
tune, and one of ft. pfr, „ thr ..„„„„„„ „ ^ ^ ^ ^ 

a queue, such that requests for at least two distinct meetings M-A and M-B, disjoin, in 

time, are placed in the queue; 

a first server system associated with the requester cornrnonp^ system, ,he firs, server 
system for determining -"O^rffc^^o^p^^^ ^^^^^^ 

the r e questor common party; 

a second server system associated with the non-cnmmon r ^y ~ » system 
ftesecondserversystemfordeternnnmgavailabilifyof.Marget^a^ 
ESjamifcA and sending the availability of the mk.^^^ , targetparty^A- 

a third server system associated with the non-cv r ,„ y ,- „ , . , nrrr , .. ' „ 

tturd server system for determining availability of Ma^arty** H.^^,^ 
Mi and sending the availability of (he targeHasW-B Hhe p ,„ T ,.„«,. ^ 

a dec.dmg agent in communication with the first server system, the second server system 
and the tlurd server system, the deciding agent for recording the requests for the real time- 
meetings M-A and M-B, for receiving an indication that whejher each roster parti and (ho 

ofjhejhree parties are avai.able for me respective real time meetings M-A 
and M-B, for determining whether the requester con™* party and one or more targe, njat 
sommon parties are mutually available for the respective real time meetings M-A and M-B and 
for nutiating one erte* of ,he real time meetings M-A and M-B when me requester party and 
the respective target parties T-A and and T-B are mutually available. 

33. (Currently Amended) The system of claim 32, wherein ennh of m, furtuu >o. 

" ' '^ M t " ' ' ' " ' 1 U 'I J H . L a qu nn , ft, d,. ,u U U rn , 

meeteg any of me party, m record tin, ft, system s n o„lH ... nf „„ ,, 

associated party to thfi d^i^r 

34. (Previously Presented) The system of claim 32, wherein each of ft. firs, server 
system and the second server system is further adapted ,o delete ,he reques, for fte real time 

meeting. 
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1 35. (Currently Amended) The system of claim 32, wherein the deciding agent is 

2 further adapted to communicate to th e first s e rv e r syst e m to any of the party's systems to cease 

3 sending an indication that the r e qu e st e r associated party is available for the real time meeting. 

1 36. (canceled) 

1 37. (Currently Amended) The system of claim 32, wherein the deciding agent is 

2 further adapted to poll the first server system to determine the availability of the r e qu e st e r 

3 common party. 

1 38. (Currently Amended) The system of claim 32, wherein the deciding agent is 

- 2 further adapted to poll at least one of the second and third server syst e m systems to determine 

3 the availability of the targ e t party. 

1 39. (Currently Amended) Th e syst e m of claim 32, wh e r e in th e d e ciding ag e nt is 

2 locat e d at th e target syst e m. The system of claim 32, wherein the decider system is part of the 

3 first server system associated with the common party, and wherein the decider already knows 

4 the status of the party for which it is responsible. 

1 40. (Currently Amended) The system of claim 32, wherein the requester syst e m i s 

2 systems are further adapted to record the request to conduct the real time meeting. 

1 41 . (Currently Amended) The system of claim 32, wherein the target syst e m is 

2 systems are further adapted to reject a request to add one or more target parties to the real time 

3 meeting and to communicate the rejection to the deciding agent. 

1 42. (Currently Amended) The system of claim 32, wherein the deciding agent is 

2 further adapted to receive an indication that th e r e qu e st e r party and one or more targ e t parties are 

3 available by monitoring the activity of the r e quest e r party and on e or mor e target parties. 

1 43. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is conducted using a telephone. 

1 44. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is conducted using Internet telephony. 
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1 45. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is specified as a face-to-face meeting M-A. 

1 46. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is specified as a text chat. 

1 47. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is an online collaboration tool. 

1 48. (Previously Presented) The system of claim 32, wherein the real time meeting 

2 M-A is a shared application. 

1 49. (Currently Amended) The system of claim 32, further comprising the presence on 

2 M-A of a plurality of request e r non-common parties and a plurality of targ e t parties , and wherein 

3 the deciding agent initiates the real time meeting when a quorum of tho requestor partioo and 

4 target parti e s all the parties is available. 



1 50-52. Canceled 

2 

1 53. (Currently Amended) A computer program product stored on a computer 

2 readable medium for intermediation of real time meetings, the computer program product 

3 comprising: 

4 program code for receiving an indication that a requester party R^A wants to request a 

5 real time meeting M-A with a target T-A; 

6 program code for receiving an indication that fee a requester party R-B wants to request a 

7 real time meeting M-B with a target T-B, such that one of the part ies to M-A. known as the 

8 'common party' is also the same as one of the parties to M-B a nd thus there are only three 

9 distinct parties, the meetings M-A and M-B being disjoint in time; 

1 0 program code means for placing in a queue requests for the two distinct meetings M-A 

1 1 and M-B, disjoint in time; 

1 2 pro gram code for receiving information indicating the availability of the r e qu e st e r 

13 common party and the target partioo T A and T B non-comm o n parties to M-A and M-B to 

1 4 participate in the real time meetings M-A and M-B, the information sent by the respective parties 

1 5 and indicating a desire of a human being to take part in a meeting; 
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1 6 program code for determining that the common request e r party and one or mor e npn; 

1 7 common targ e t parties T- A and T-B are mutually available to participate in the real time 

1 8 meetings M-A and M-B, in response to the received information; and 

1 9 program code for initiating respective meetings M-A and M-B, responsive to the 

20 determination that the requ e st e r common party and at least one of target partios T A and T B the 

2 1 non-common parties are mutually available to participate in the respective real time meetings M- 

22 A and M-B. 
23 

1 54. (Previously Presented) The method of claim 1 , further comprising displaying the 

- 2 availability status of the requester on the target system, along with an indication that the 

3 requester has requested a meeting. 

1 55 . (Previously Presented) The method of claim 54, wherein the availability status is one 
. 2 of in, out, and unknown. 

. 1 56. (Previously Presented) The method of claim 1 , further comprising displaying an 

2 availability status of the target T- A on the requester system, along with an indication that the 

3 requestor has requested a meeting with the target. 

1 57. (Previously Presented) The method of claim 56, wherein the availability status is one 

2 of in, out, and unknown. 

1 58. (Withdrawn) A user interface displayed on a target system, comprising: 

2 a display showing an ID of a requesting user who has requested a meeting with 

3 the target; and 

4 a display showing an availability status of a requesting user, the availability status 

5 sent by the requesting user. 

1 59. (Withdrawn) The user interface of claim 58, wherein the availability status is one of 

2 in, out, and unknown. 

1 60. (Withdrawn) The user interface of claim 58 showing an age of the request for a 

2 meeting. 
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1 61 . (Withdrawn) The user interface of claim 58 showing a priority of the request for a 

2 meeting. 

1 62. (Withdrawn) The user interface of claim 58 showing a reason for the requested 

2 meeting. 

1 63. (Withdrawn) The user interface of claim 58 showing additional information about the 

2 requesting user. 

1 64. (Withdrawn) A user interface displayed on a system of an owning user, comprising: 

• 2 a display showing an ID of a requesting user who has requested a meeting with the 

3 owning user and an availability status of the requesting user, the availability status sent by the 
• 4 requesting user; 

5 the display further showing an ID of a target user with whom the owning user has 

6 requested a meeting, and the availability status of the target user sent by the target user. 

1 65. (Withdrawn) The user interface of claim 64, wherein the availability statuses are one 

2 of in, out, and unknown. 

1 66. (Withdrawn) The user interface of claim 64, showing an age of the request for a 

2 meetings. 

1 67. (Withdrawn) The user interface of claim 64, showing a priority of the request for a 

2 meetings. 

1 68. (Withdrawn) The user interface of claim 64, showing a reason for the requested 

2 meetings. 

1 69. (Withdrawn) The user interface of claim 64, showing additional information about 

2 the requesting user. 



1 70. (Withdrawn) The user interface of claim 58, wherein the ID of the requesting user 

2 and the availability status of the requesting user are displayed in a single display box. 
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71 . (Withdrawn) The user interface of claim 64, wherein the ID of the requesting user 
and the availability status of the requesting user are displayed in a single display box. 

72. (New) The method of claim 1, wherein the decider system a part of the system of the 
common party for whom it is responsible, and wherein the decider already knows the status of 
the common party for which it is responsible. 

73. (New) The method of claim 1, wherein the decider system chooses to activate one of 
two real time meetings to activate based on at least one of: 

ranking information including manual ranking through a user interface presented to the common 
party; 

priority information provided by either party; 

the order in time in which the requests were made; and 

relationship information about the parties based on party input or past history. 
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